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1.  General  Infbnnation 

The  Digital  Voice  Gateway  (referred  to  as  the 'DVG' in  this  document)  transmits  and 
receives  four  fuU  duplex  encoded  speech  chaimels  over  the  Ediemet  The  information 
in  this  document  applies  only  to  DVGs  running  firmware  of  ihe  version  listed  on  the 
title  page. 

This  document,  previously  named  Digital  Voice  Gateway  Reference  Guide,  BBN 
Systems  and  Technologies  Corporation,  Cambridge,  MA  02138,  was  revised  for 
revision  2.00.  This  new  revision  changes  the  network  protocol  used  by  the  DVG,  to 
comply  with  the  SINCGARS  radio  simulation  (For  SIMNET  6.6.1).  Because  of  the 
extensive  changes  to  revision  2.00  a  separate  document  was  created  rather  than 
supplying  change  pages. 

1.1.  .  What  Is  Covered  In  This  Guide 

This  guide  presents  an  overview  of  the  DVG  hardware  and  software  to  a  level  of 
detail  such  that  the  reader  can  imderstand  the  types  of  processing  performed  by  the 
DVG  as  well  as  debug  many  common  system  problems.  It  also  presents  how  to 
configure  the  hardware  and  software  components  of  the  DVG.  This  guide  does  not 
address  die  incorporation  of  the  DVG  into  larger  systems  or  connection  to  specific 
sources  of  voice  sudi  as  CB  radios  or  other  audio  equipment 

1.2.  Related  Documentation 

The  SIMVAD  speech  coding  board  is  described  in  the  following  two  BBN  STC  reports: 

SIMVAD  Hardware  Documentation 

SIMVAD  System  Real-Time  Software  Documentation 

Also,  the  following  Motorola  publications  are  tiseful  in  working  with  the 
MVME147  CPU  hardware  and  its  firmware  debugger,  147Bug: 

MVME147  MPU  and  MVME712  Transition  Module  User’s  Manual 

MVME147Bug  User's  Manual 

The  DVG  version  2.00  iises  a  subset  of  the  SINCGARS  simulation  protocol  (which  will 
be  discussed  briefly  in  die  section  entitied  Protocol  Format).  This  protocol  is  detailed  in 
the  following  document. 

SIMNET  SIMULATION  OF  RADIO  COMMUNICATION:  A  Testbed  for 
Investigation  Combat  Vehicle  C3I  Technology.  Report  No.  7352  (SIMNET 
LIBRARY  serial  #  50074) 
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2.  System  Description 

The  DVG  consists  of  a  high  performance,  high  level  of  integration  CFU  mated 
witil\  special  piupose  speech  coding  hardware  in  an  industry  standard  VMEbus 
enclosure.  The  software  diat  controls  the  DVG  resides  in  EPROMs  on  the  CPU  board. 

An  overview  of  die  DVG  hardware  and  firmware  will  be  presented  in  this  section. 

2.1.  Hardware  Description 

2.1.1.  MVME147CPU 

The  Motorola  MVME147  CPU  controls  the  DVG.  It  performs  all  network  input  and 
output,  controls  and  initializes  the  SIMVAD  speech  coding  boards,  and  interfaces  to  the 
DVG  terminal  port.  It  has  the  following  features: 

MC68030  microprocessor  running  at  25  MHz 

MC688^  floating-point  processor 

4  MB  of  dynamic  RAM  expandable  to  16  MB 

4  serial  ports 

SCSI  interface 

time  of  day  dock 

2  KB  of  battery  backed  RAM 

debugger  in  ROM 

VMEbus  system  controller 

reset  and  abort  switches 

printer  port 

Ethernet  interface 

2.1.2.  MVME712  Transition  Module 

The  Motorola  MVME712M  Transition  Module  provides  the  input/output 
connections  for  the  MVME147  CPU.  It  connects  to  the  MVME147  via  an  adapter  board 
plugged  into  the  P2  VMEbus  connector  of  the  slot  that  the  MVME147  is  plugged  into. 
Die  MVME712M  is  mounted  on  the  rear  of  the  DVG  chassis  and  provides  connections 
for  the  Ethernet  transceiver  cable  and  the  DVG  terminal  port.  Three  other  serial  ports, 
a  SCSI  port  and  a  printer  port  on  the  MVME712M  are  imused  by  the  DVG. 
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2.13.  SIMVAD  Speedi  Coding  Board 

The  SIMVAD  speedi  coding  board,  developed  and  manufactured  by  BBN  STC, 
consists  of  two  complete  and  independent  full  duplex  speech  coding  channels  on  a 
single  6U  VMEbus  module.  The  standard  DVG  supports  four  voice  channels  and 
hence  contains  two  SIMVAD  boards.  Each  channel  consists  of  the  following 
components: 

TM5320C25  signal  processor 

32  KW  data  RAM 

32  KW  program  RAM 

16  KW  program  ROM 

A/D  and  D/A  converter 

512  Words  eadi  of  input  and  output  ftfb 

Each  channel  uses  fheAPCHQ  coding  algorithm  (in  firmware)  to  encode  and  decode 
speech  at  a  16  Kbit  per  second  or  32Kbit  per  second  rate.  As  used  in  the  DVG,  the 
SIMVAD  supports  an  input  voltage  range  of  +/-  3  volts,  differential  and  an  output 
range  of  +/-  6  volts,  differential. 

2.1.4.  VMEbus  Chassis 

The  DVG  chassis  is  a  12-slot,  6U,  rack  mountable  unit  with  integral  fans 
manufactured  by  Mupac.  The  power  supply  is  rated  at  400  Watts  and  provides  the 
following  outputs: 

Voltage  (Volts)  Maximum  Current  (Amps) 


+5 

70 

+12 

10 

-12 

10 

-5 

2 

Input  power  is  via  a  standard  15  Amp,  single  phase,  120  Volt,  three  wire  power  cord. 
The  DVG  draws  approximately  3  Amps  at  120  Volts  when  operating. 

23.  Firmware  Description 

The  DVG  firmware  runs  as  a  single  program  in  complete  control  of  the  MVME147 
CPU.  All  network  juid  voice  channel  processing  is  performed  in  the  context  interrupts 
generated  by  a  selected  SIMVAD  voice  coding  bovd.  Terminal  I/O  is  handled  in  the 
foreground  using  system  functions  provided  by  147Bug,  the  MVME147s  EPROM- 
resident  debugger.  Ihis  section  will  describe  in  some  detail  the  functions  performed  by 
the  firmware. 
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2JL1.  Boot-up  and  Initialization 

The  DVG  firmware  is  designed  to  perform  its  initialization  tasks  from  power-up  or 
front  pand  reset  and  enter  its  main  processing  loop  widiout  user  intervention.  Booting 
takes  about  10  seconds.  Fbr  debugging  and  configuration  purposes^  however^  it  is 
important  to  be  familiar  with  the  sequence  of  events  that  lead  from  a  reset  to  full 
operation. 

The  typical  output  from  the  DVG  console  port  after  a  reset  or  power  cycle  is  shown 
below. 

Copyright  Motorola  Inc  1988,  All  Rights  Reserved 
VME147  Monitor /Debugger  Release  2.0  -  3/16/89 
FFC  passed  test 
MMU  passed  test 
COLD  Start 

147-Bug>  Searching  for  ROM  Boot 
147-Bug>G  FFAOOOOE 
Effective  address:  FFAOOOOE 
Digital  Voice  Gateway 

version  2.0.0  of  Thu  Nov  16 15:36:47  EST 1993 
LORAL  Systems  Corporation 
Orlando,  FL  32826 
Initializing  timers. 

Initializing  clock  interrupt 
Initializing  network. 

Ethernet  Address:  08003e204674 
Initializing  SIMVAD  cards. 
channelO:  foimd  at  OxeOOO. 
channell:  found  at  OxeOOO. 
channel2:  foimd  at  OxelOO. 
channel3:  found  at  OxelOO. 

Initializing  keyboard. 

VG> 
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The  DVGfiraiware  receives  control  from  the  147Bug  debugger  following  power-up  or 
front  pand  reset  The  firmware  first  copies  itsdf  from  address  QxFFAOOOOO  (in  EPROM) 
to  address  (b^OOO  (in  RAM),  the  address  it  was  linked  to  run  at.  Control  is  then 
transfdred  to  die  firmware  copy  at  address  0x6(X)0  and  initialization  continues.  Ihe 
firmware  runs  out  of  RAM  because  memory  accesses  to  RAM  are  faster  than  those  to 
EPROM  on  the  MVME147  CPU. 

After  printing  out  a  banner,  the  firmware  proceeds  to  initialize  its  various  subsystems: 
timers,  interrupts,  network,  SIMVADs  and  keyboard.  Error  messages  are  printed 
slu>uld  initialization  fail  and  control  will  be  returned  to  147Bug  in  the  event  of  a  fatal 
error. 

During  network  initialization,  the  Ethernet  address  programmed  into  a  PROM  on  the 
MVME147  CPU  is  displayed  as  shown  in  the  above  printout.  This  address  will  of 
course  be  difrerent  for  ea^  DVG. 

During  SIMVAD  initialization,  each  pair  of  channels  (corresponding  to  a  single 
SIMVAD  board)  is  checked  for  existence  and  a  message  is  printed  as  shown  below  for 
eadi  channel  foimd.  Each  SIMVAD  board  is  then  reset  (its  two  red  LEDs  blink  once 
together  when  this  operation  is  performed)  and  the  diagnostic  status  returned  by  the 
SIMVAD  firmware  is  checked  by  the  DVG  firmware.  The  possible  diagnostic 
messages  that  could  be  printed  are: 

svN:  diagnostics:  TMS  Operation  Error 

svN:  diagnostics:  EPROM  Error 

svN:  diagnostics:  Program  RAM  Error 

svN:  diagnostics:  Data  RAM  Error 

svN:  diagnostics:  D/ A-A/D  Test  Error 

The  particular  voice  channel  that  failed  is  indicated  by  'svN',  where  N  is  the  channel 
number.  The  first  four  types  of  failures  (bad  Th^  32(K:!25,  bad  EPROM  checksum, 
and  RAM  errors)  indicate  a  bad  SIMVAD  board.  The  fifth  error  (D/ A-A/D  Test 
Error),  however,  can  occur  without  a  board  being  bad.  The  D/ A-A/D  test  is 
performed  by  outputting  a  triangle  wave  on  the  D/A  output  and  comparing  it  with 
the  signal  measured  on  the  A/D  input.  If  the  difierence  is  too  great,  the  'D/ A-A/D 
Test  Error'  is  reported.  This  error  can  occur  if  there  is  too  much  noise  pickup  on  the 
cables  connected  to  the  SIMVAD  boards  as  well  as  if  die  analog  input  circuitry  on  the 
SIMVAD  is  bad,  so  its  occurrence  should  be  regarded  with  suspicion.  A  good  test  is  to 
disconnect  the  input  cable  and  reset  the  DVG  again  -  if  the  error  persists,  then  the 
SIMVAD  should  be  suspected. 

Following  SIMVAD  initialization,  the  lowest  numbered  voice  channel  found 
(generally  niunber  0)  is  initialized  to  generate  an  interrupt  at  the  SIMVAD  frame  rate 
(26.25  milliseconds).  The  service  routine  for  this  interrupt  handles  all  processing  for 
the  voice  channels  as  well  as  the  higher  level  network  input/output  processing  as 
described  in  later  sections. 
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Bnally,  die  terminal  interface  is  initialized  and  the  DVG  prompt  CVG>')  is  printed 
on  the  console  port.  The  DVG  firmware  then  enters  its  main  processing  loop  and 
begins  to  service  die  voice  channels  and  the  network. 

2.2.2.  Protocol  Format 

A  brief  discussion  of  the  SINCG  ASS  protocol  follows.  It  is  provided  so  that  the  reader 
may  understand  die  operations  of  the  DVG  software. 

Version  200  of  die  DVG  uses  a  subset  of  the  SIMNET  SINCG  ASS  simulation  protocol. 
Mainly  DVG  2.00  does  not  use  a  receiver  PDU,  which  is  implemented  in  SINCGARS 
simulation.  The  DVG  does  not  incorpiorate  any  terrain  modeling  for  signal  degradation. 
The  DVG  does  use  the  remaining  transmitter  and  signal  PDUS.  To  conform  to  the 
SINCGARS  radio  simulation  the  DVG  produces  one  transmitter  PDU,  fw  each  radio  it 
is  simulating,  every  5  seconds.  The  transmitter  PDU  contains  information  including: 
radio  id,  location,  frequency,  <uid  state  of  the  transmitter  (and  whether  it  is  a  change 
from  the  last  transmission).  Signal  PDUs  are  produced  whenever  valid  speech  data  is 
acquired  from  the  SIMVAD  boards.  The  signal  PDUs  contain  information  including: 
radio  id  and  coded  speech  data. 

A  transmitter  PDU  is  sent  whenever  the  state  of  the  transmitting  radio  has  changed  or  5 
seconds  has  elapsed.  Signal  PDUs  are  sent  whenever  valid  data  is  received  from  a 
SIMVAD  board.  The  SIMVAD  boards  produce  data  in  56  byte  buffers,  one  buffer 
makes  up  the  data  portion  of  the  signal  PDU.  Signal  PDUs  are  sent,  until  the  SIMVAD 
board  supplying  the  buffers,  no  longer  produces  valid  data. 

22.3.  Network  Service 

The  network  is  serviced  from  within  the  handler  for  the  frame  interrupt  set  up  as 
described  in  the  'Boot-up  md  Initialization*  section.  This  module  drains  the  queue 
of  received  piackets  on  eadi  invocation.  It  discards  all  packets  that  do  not  correspond  to 
the  correct  protocols  (0x86  and  0x89),  or  the  PDU  kind  is  not  a  Transmitter  or  Signal 
PDU,  or  the  packet  is  from  a  difierent  exercise.  (Exercise  ID  will  be  discussed  later)  A 
buffer  is  allocated  (from  a  pool  of  free  buffers)  for  each  received  packet. 

If  the  packet  contains  a  transmitter  PDU,  the  frequency  information  within  this  PDU  is 
stored  in  a  hash  table  (the  hash  value  is  obtained  using  the  radio  id).  When  a  signal 
PDU  is  received,  a  search  is  made  in  the  hash  table  using  the  radio  id  obtained  within 
the  signal  PDU.  If  no  match  is  found  the  packet  is  discarded.  If  a  match  is  found  a 
header  is  set  up  to  point  to  the  speech  data  within  the  PDU.  The  headers  are  passed  to 
the  SIMVAD  software  mcxiule  for  transmission  to  the  appropriate  SIMVAD  card.  A  use 
count  is  maintained  in  the  buffer  so  that  when  the  SIMVAD  software  module  has 
freed  all  its  accesses  to  the  buffer  (i.e.,  the  headers),  the  buffer  can  be  returned  to  the 
free  p<x)l. 

Transmission  of  signal  and  transmitter  packets  over  the  network  occurs  as  a  result  of 
calls  from  the  SIMVAD  software  module  into  the  network  software  mcxiule.  The 
SIMVAD  software  mcxiule  places  speech  frames  into  a  buffer  allocated  from  the  free 
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pool  by  the  network  software  module.  An  Ethernet-  header  is  prepended  to  the 
bxiffer  and  the  packet  is  transmitted  over  the  network  when  die  maximum  number  of 
speech  frames  per  packet  is  reached  (currently  the  maximum  is  1),  when  the 
maximum  Ethernet  packet  size  if  reached,  or  when  a  'flush*  function  is  called  by  the 
SIMVAD  sctftware  module  (always  called  at  the  end  of  the  ftame  interrupt  to  insure 
diat  all  buffered  data  is  transmitt^  with  only  small  latency).  All  packets  transmitted 
over  the  network  are  also  turned  around  and  processed  by  the  receiving  software  to 
allow  channels  in  loopback  mode  to  receive  their  own  frames  back. 

12.4.  SIMVAD  Service 

The  SIMVAD  voice  channels  are  serviced  from  within  the  context  of  the  frame 
interrupt  set  up  as  described  in  the  section  'Boot-up  and  Initialization'.  The  ft'ame 
queue  on  each  SIMVAD  is  drained  and  the  frames  are  placed  in  a  buffer  allocated  by 
the  network  software  module  and  transmitted  by  the  network  software  module.  When 
a  frame  of  data  is  received  from  a  SIMVAD  board,  a  check  is  made  to  determine  if  the 
data  is  valid  or  just  noise  created  by  the  SIMVAD  board  or  a  signal  diat  does  not  reach 
the  set  threshold  level.  If  the  data  is  valid  further  checks  are  made  to  determine  the 
state  of  the  transmitter.  If  a  new  state  is  indicated  a  new  transmitter  PDU  will  be  sent. 
Logic  in  the  software  determines  if  the  signal  PDU  is  the  last  of  its  transmission.  If  so 
the  sync  field  within  the  PDU  indicates  this  by  the  End  Of  Message  sync,  if  not  fiie  sync 
field  is  normaL  Also,  timing  routines  which  send  transmitter  PDUs  every  5  seconds  are 
maintained,  and  a  group  of  signal  PDUs  will  be  interrupted  to  send  a  new  transmitter 
PDU  if  necessary. 

The  SIMVAD  software  module  receives  headers  that  point  at  speech  frames  within  a 
network  piacket  in  a  buffer.  It  will  en  queue  these  frames  on  the  appropriate  SIMVAD 
card  after  introducing  a  frame  of  delay  for  the  first  frame  of  a  sequence  of  frames  in 
an  attempt  to  reduce  the  probability  of  an  anomaly  due  to  variable  transmission 
delays  for  the  packets  containing  an  utterance. 

The  SIMVAD  softwjire  module  attempts  to  "lock  on"  to  a  particular  source  of  speech 
so  as  to  eliminate  the  anomalies  due  to  interleaving  the  speech  frames  from  more  than 
one  source.  The  algorithm  is  essentially  to  maintain  a  state  variable  for  each  channel 
fiiat  can  be  either  'idle'  or  'playing'.  If  the  channel  is  'idle',  the  first  frame  destined 
for  a  particular  channel  is  played,  the  source  is  noted  and  the  state  is  set  to 'pla)dng’. 
As  long  as  frames  continue  to  be  received  from  the  same  source,  they  are  played 
and  the  state  is  maintained  as  'playing'.  Frames  destined  for  the  channel  from  other 
sources  are  discarded.  When  no  more  frames  from  the  source  that  has  been  "locked 
onto"  are  received,  the  state  is  set  back  to  'idle'  and  once  again  all  sources  can  "compete" 
for  the  channel. 


22.5.  Ethernet  Speech  Packet  Format 

The  Ethernet  packets  generated  by  the  DVG  conform  to  the  Radio  PDUs  in  the 
SINCGARS  Radio  Simulation.  Of  those,  the  transmitter  and  signal  PDUs  are  utilized 
(the  receiver  PDU  is  not  implemented  on  the  DVG). 
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The  Ethernet  packet  has  tfie  format  shown  below.  The  default  Destination  Address  for 
transmitter  and  signal  packets  are  as  follow:  Transmitter  030000000086,  and  signal 
030000000069  (hex).  The  Ediemet  t3rpe  is  21000  for  both  transmitter  and  signal  packets. 
The  Source  Address  is  obtained  from  the  ROM  on  the  CPU  board.  By te  offsets  from  the 
start  of  the  packet  are  shown  for  each  component. 


Byte  count  starts  with  1. 


802.2/8023  packets: 


MAC 


SAP 

SNAP 


DESTINATiasi6 
SOURCE 6 


LENGTH  2 


DSAPl 

SSAPl 

CNTLl 

org.code: 

3 

ETHER_TYPE2 

DATA  46-1492 


CRC4 


LENGTH  is  the  number  of  bytes  following  the  MAC  header  (the  DESTINATION, 
SOURCE,  LENGTH). 

SAP  (Service  Access  Point)  header  spedEes  ports  on  the  source  and  destination 
machines  and  the  type  of  service. 

DSAP  is  the  destination  service  access  point. 

SSAP  is  the  source  service  access  point. 

CNTL  is  the  type  of  service  (we're  using  3  which  is  "unnumbered  service"). 

The  SNAP  (Sub-Network  Access  Point)  header  is  present  only  if  DSAP  ==  SSAP  == 
OxAA  ==  170  (this  is  what  we  do). 

ORG_CODE  is  an  organization  code  (we're  using  0). 

ETHER_TYPE  is  the  type  of  the  encapsulated  protocol  (in 

our  case,  21000). 

The  data  link  layer  (in  the  ISO  protocol  stack)  is  split  into  two  sublayers: 

LLC  ==  Link  Layer  control 
MAC  ==  Media  Access  Control 
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The  new  format  is  shown  below  in  terms  of  C  language  structures: 

/*  An  Ethernet  header  (version2.0,  not  802.3):  */ 
typedef  struct  { 

NetworkAddress  to; 

NetworkAddress  from; 
short  type; 

)  NetworkHeader; 

/*  An  Ethernet  header  (802.3,  not  version2.0);  *! 
typedef  struct  { 

NetworkAddress  to; 

NetworkAddress  from; 
short  length; 

)  NetworkHeader8023; 

/*  An  Ethernet  packet  (version2.0):  */ 
typedef  struct  { 

NetworkHeader  hdr; 

char  data(NETWCRK_BUFFER_SIZE]; 

)  NetworkBuffer; 

/*  An  Ethernet  packet  (802.3):  */ 
typedef  struct  { 
iinion  { 

NetworkHeader  hdr2; 

NetworkHeader8023  hdr8023; 

}h; 

char  data[NETWORK_BUFFER_SIZE]; 

}  NetworkPacket; 

Notice  that  the  structures  are  set  up  so  that  it  is  easy  to  implement  DVG  that  will 
accept  both  the  version2.0  packets  and  8023  packets.  First,  check  length  in  the  header 
and  if  it  is  larger  than  maximum  packet  lengtfi  then  it  is  version2.0  (version2.0  saves 
type  in  this  Held).  However,  there  is  no  foreseeable  need  in  handling  version2.0 
packets,  so  that  1.43  and  2.00  DVG  does  not  implement  this  feature.  In  8023  format 
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DSAP  and  SSAP  are  stored  before  the  data,  there  are  macros  to  get/set  DSAP,  SSAP 
and  data  information.  Fbllowing  are  the  C  macros: 

#define  GET_DSAP(p)  (((unsigned  char  •)(p))[0]) 

#define  GET_SSAP(p)  (((unsigned  char  *)(p))Ill) 

#define  GET_CONTROL(p)  (((unsigned  char  •)(p))[2]) 

#define  GET_PROTOID(p)  ((((unsigned  char  *)ip))[3] « 16)  I 

(((unsigned  char  *)(p))[4]  «  8)  I 

((unsigned  char  *)(p))[51) 

#define  GET_ETHER_TYPE(p)  (((unsigned  short  •)(p))[31) 

#dcfine  GET_DATA_PTR(p)  ((unsigned  char  ‘Xp)  +  8) 

#define  SET_DSAP(p,x)  (((imsigned  char  *)(p))[0]  =  (x)) 

#define  SET_SSAP(pp()  (((unsigned  char  •)(p))[l]  =  (x)) 

#define  SET_CONTROL(p,x)  (((unsigned  char  *)(p))[2l  =  (x)) 

#define  SET_PROTOID(ppc)  ((unsigned  char  •)(p))[3]  =  (x) » 16; 

((unsigned  char  *)(p))(4]  =  (x) »  8; 

((unsigned  char  *)(p))[5j  -  (x) 

#define  SET_ETHER_TYPE(ppc)  ((unsigned  short  •)(p))[3l  =  (x) 

2.2.6.  Terminal  Interface 

The  DVG  supports  a  terminal  interface  used  for  debugging,  development  and 
configuration.  From  this  interface,  various  system  and  performance  parameters  may 
be  entered  and/or  examined.  The  DVG  terminal  interface  may  be  accessed  via  the 
CONSOLE  port  1  connector  at  the  rear  of  the  unit.  See  the  section  on  'Hardware 
Configuration'  details. 

The  terminal  interface  is  command  line  oriented,  i.e.,  the  user  types  commands  and 
parameters  in  response  to  a  prompt.  Each  of  the  available  commands  and  their 
resulting  output  will  be  illustrated  cind  described  in  the  following  pages. 
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The  ccmunand  interface  supp>orts  simple  line  editing  via  sequences  of  control 
characters/  a  list  of  these  folow: 

'^p  previous  line 

^  next  line 

bade  one  character 

^f  forward  one  character 

^d  delete  duoracter  under  cursor 

^a  go  to  beginning  of  line 

'^e  go  to  end  of  line 

^s  delete  previous  character 

Commands  and  parameters  are  separated  by  spaces.  Entire  commands  need  not  be 
typed  (although  all  examples  below  will  use  fully  typed-out  commands)  only  enough 
letters  to  differentiate  the  command  from  all  oth^  at  that  point  in  the  parsing  must  be 
typed.  Help  about  the  possible  choices  at  any  point  may  be  obtained  by  typing  a 
'?'.  Typing '?' immediately  after  a  command  gives  a  single  line  of  help  about  that 
command  while  typing '?'  after  a  space  or  at  the  beginning  of  a  line  gives  all  the  possible 
choices  at  that  point  In  all  the  examples  that  follow,  the  DVG  prompt  is  displayed  as 
•VG>’. 

2^6.1.  Top  Level 

The  top  level  of  commands  may  be  viewed  by  typing  ’?'  as  show  below: 

VG>? 

Commands: 


voice 

’Voice  channel  commands 

radio 

-radio  commands 

network 

-network  commands 

system 

-system  conunands 

config 

-configuration  commemds 

exit 

-exit  program 

quit 

-exit  program 

help 

-parser  editor  help 

Each  of  these  commands  or  command  groups  will  be  explained  in  the  sections  that 
follow. 
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0  Voice  Command  Group 

The  voice  command  group  contains  commands  related  to  the  voice  input  and  output 
dumneb.  The  voice  commands  may  be  viewed  by  typing  a*?  after  entering  the  'voice' 
command  (followed  by  a  space),  as  shown  below: 

VG>  voice  ? 

Voice  Channel  Commands: 


loopback 

-set  or  show  loopback  status 

pushtotalk 

-set  or  show  pushtotalk  check  status 

speechvalid 

-set  or  show  speech  level  check  status 

threshold 

-set  or  show  threshold 

rate 

-set  or  show  coding  rate 

activity 

-set  or  show  on/off  status 

mapping 

-set  or  show  frequency  to  physical  channel  mapping 

statistics 

-show  statistics 

zerostatistics 

-zero  statistics 

restart 

-restart  simvads 

12.6JL1.  Loopback 

The  voice  channels  may  be  placed  in  loopback  mode  (input  connected  to  output)  via 
the  'loopback'  command.  In  this  mode,  all  incoming  spee^  frames  are  output  on  the 
same  duumel  that  they  were  input  horn.  A  single  channel  may  be  put  into  loopback 
mode  by  entering  the  line 

VG>  voice  loopback  set  N  on 

where  N  is  the  channel  number  to  put  into  loopback  mode.  Likewise,  loopback 
mode  may  be  turned  off  for  a  single  ^annel  by  entering  the  line 

VG>  voice  loopback  set  N  off 

where  N,  is  again,  the  channel  number  to  take  out  of  loopback  mode.  All  channels  may 
be  put  into  or  taken  out  of  loopback  mode  by  (respectively)  typing  the  lines 

VG>  voice  loopback  all  on 

VG>  voice  loopback  all  off 
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Hnally,  the  loopback  status  of  each  channel  may  be  displayed  as  follows.  The  display 
shown  below  is  for  the  case  where  loopback  is  off  for  all  the  channels. 

VG>  voice  loopback  show 

channel  on/off 

0  OFF 

1  OFF 

2  OFF 

3  OFF 

The  loopback  is  accomplished  in  software  -  no  hardware  connection  is  made.  All 
speedi  frames  input  from  the  channels  in  loopback  are  still  directed  to  the  network^ 
however,  and  all  speech  frames  from  the  network  diat  are  directed  to  channels  in 
loopbadc  mode  are  discarded,  i.e.,  they  are  not  output. 

Loopback  mode  is  particularly  useful  for  debugging.  The  functionality  of  a 
particular  voice  channel  may  1^  verified  by  placing  the  channel  in  loopback  mode, 
driving  the  input  with  a  known  waveform,  and  attempting  to  observe  the  resulting 
wave  form  (afrer  coding,  passing  through  the  internal  software  path  and  then 
decoding)  at  the  outputs  on  the  same  channel.  Also,  loopback  mode  may  be  used  in 
conjimction  with  the  voice  statistics  (see  below)  coiiunand  selection  to  verify  that  the 
system  is  passing  frames  from  input  to  output  without  depending  on  a  working 
network  cormection. 

2^6.2^  Pushtotalk 

The  'pushtotalk'  command  allows  push-to-talk  checking  to  be  enabled  or  disabled  for 
the  voice  channels.  The  default  condition  is  for  push-to-talk  checking  to  be  enabled, 
i.e.,  if  the  push-to-talk  input  for  a  channel  is  asserted,  an  input  frame  (read  from  the 
Icx^  chaimel)  will  be  passed  to  fiie  network  while  if  it  is  deasserted,  the  frame  will  be 
discarded. 

Push-to-talk  checking  may  be  turned  on  or  off  for  a  single  channel  by  t)rping  the 
commands  (respectively) 

VG>  voice  pushtotalk  set  N  on 

VG>  voice  pushtotalk  set  N  off 

where  N  is  the  chemnel  to  affect.  Checking  may  be  himed  on  or  off  for  all  channels 
by  typing  the  commands  (respectively) 

VG>  voice  pushtotalk  all  on 

VG>  voice  pushtotalk  all  off 

Finally,  the  status  of  push-to-talk  checking  may  be  displayed  as  follows.  The 
display  shown  below  is  for  the  case  of  checking  turned  on  for  all  channels. 
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VG>  voice  pushtotalk  show 
diaimel  on/off 

0  ON 

1  ON 

2  ON 

3  ON 

The  SIMV  AD  voice  coding  boards'  push-to-talk  inputs  naturally  float  to  an  asserted 
level.  This  results  in  a  flood  of  packets  on  the  network  for  any  channel  that  has 
floating  inputs  since  it  appears  to  the  DVG  software  that  the  push-to-talk  input  is 
always  asserted.  This  command  is  useful  in  debugging  because  it  can  be  used  to  force 
the  speech  frames  from  a  particular  voice  channel  to  be  placed  on  the  network 
independent  of  the  state  of  the  channel's  push-to-talk  input  This  can  be  an  aid  in 
isolating  a  fault  to  push-to-talk  circuitry  connected  to  a  DVG  voice  channel. 

12.6.2.3.  Speechvalid 

The 'speechvalid*  command  enables  checking  of  the  speedi-valid  bit  in  eadi  frame 
of  speech  read  from  the  SIMVAD  speech  coding  board.  The  ^MVAD  tests  a  measure 
of  the  signal  power  in  each  frame  against  a  threshold  and  sets  the  valid  bit  if  the 
power  exceeds  the  threshold.  Otherwise,  the  SIMVAD  dears  the  valid  bit  The 
default  threshold  (which  may  be  set  via  Ae  'threshold'  command)  is  0  so  that  all 
speech  will  be  considered  valid  unless  the  threshold  is  raised. 

Speech-valid  checking  may  be  turned  on  or  off  for  a  voice  channel  by  typing  the 
commands  (respectively) 

VG>  voice  speechvalid  set  N  on 

VG>  voice  speechvalid  set  N  off 

where  N  is  a  voice  channel  number.  Speech-valid  checking  may  be  turned  on  or  off 
for  all  channels  by  typing  (respectively) 

VG>  voice  speechvalid  all  on 

VG>  voice  speechvalid  all  off 

Finally,  the  speedi-valid  checking  status  for  each  channel  may  be  displayed  as 
follows.  The  example  below  is  for  the  case  of  speech- valid  checking  turned  off  for  all 
channels. 
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VG>  voice  speedivalid  show 
dumnel  on/off 

0  OFF 

1  OFF 

2  OFF 

3  OFF 

Speech'valid  checking  is  turned  otf  by  default  for  all  channels.  It  may  be  useful  for 
some  applications  that  wish  to  send  only  speech  frames  that  contain  valid  (as 
determined  by  sufficient  power)  speech. 

2.2.6.2.4.  Threshold 

The  threshold  for  speech-valid  checking  may  be  entered  via  the ‘threshold’ cxnnmand. 
The  default  threshold  is  0  for  all  channels.  The  threshold  is  used  by  the  SIMVAD  in 
determining  whether  the  input  speech  in  a  frame  is  valid,  i.e.,  has  sufficient  energy  to 
be  considered  signal  instead  of  mere  noise.  A  threshold  may  be  entered  for  a  voice 
channel  typing  foe  command 

VG>  voice  threshold  set  N  THRESHOLD 

where  N  is  a  voice  channel  number  and  THRl^HOLD  is  an  unsigned  hex  number. 
A  threshold  may  be  entered  for  all  channels  at  the  same  time  by  typing  the  command 

VG>  voice  threshold  all  THRESHOLD 

where  THR^HOLD  is  an  unsigned  hex  number.  Finally,  the  threshold  for  each 
chaimel  may  be  displayed  as  follows.  The  example  below  is  for  die  case  of  default 
thresholds  for  all  channels. 

VG>  voice  threshold  show 

channel  threshold 

0  0x00000000 

1  0x00000000 

2  0x00000000 

3  0x00000000 

2JL6.2.5.  Rate 

The  'rate'  command  allows  setting  of  the  coding  rate  of  the  SIMVAD  boards.  The  rate 
will  be  either  16  or  32  Kbps  APCHQ  coding.  The  rate  may  be  set  for  one  or  all  channels. 
The  'rate'  command  will  also  show  the  current  rates  for  all  channels.  The  following 
example  shows  the  format  for  the  'rate'  command. 
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VG>  voice  rate  show 

dumnel  rate 

0  16Kbps 

1  16Kbps 

2  16Kbps 

3  16Kbps 

VG>rateset216  ( Sets SIMVAD channel 2 to  16 Kbps AFCHQ ) 

VG>  rate  all  16  (Sets  aU  SIMVAD  channels  to  16  Kbps  AFCHQ ) 

2^6^6.  Activity 

Channeb  may  be  turned  on  or  o£f  individually  or  all  at  once.  In  previous  releases,  die 
only  way  to  disable  a  channel  was  to  pull  out  the  corresponding  board  or  to  ensure 
diat  the  push-to>talk  input  was  dbabled.  As  an  example,  channel  0  may  be  turned  off 
by  t]^ing  "voice  activity  set  Ood"  The  channel  number  must  be  a  physical  (device) 
num^.  An  example  of  the  activity  function  follows. 

VG>  voice  activity  show 


device 

frequency 

status 

svO 

33000KHZ 

ON 

svl 

43000KHZ 

ON 

sv2 

53000KHZ 

ON 

sv3 

63000KHZ 

ON 

All  channeb  may  be  turned  on  or  off  at  the  same  time  using  the  'activity  all  "on/od"' 
command.  One  channel  may  be  turned  on  or  off  by  typing  'activity  set  N  "on/ofF" 
command  where  N  represenb  the  SIMVAD  channel  number. 

2.2.6.2.7.  Mapping 

In  the  SIMCGARS  radio  protocol,  a  radio  determines  whether  to  Ibten  to  another  radios 
transmissions  based  upon  the  frequency  settings  which  are  contained  in  the  transmitter 
PDU.  A  hequency  can  be  mapped  to  a  physic^  SIMVAD  channel.  When  transmissions 
from  other  radios  set  to  die  same  frequency  are  processed,  there  signal  data  will  be 
routed  to  that  particular  SIMVAD  channel.  The  mapping  command  will  show  the 
current  settings  as  shown  below. 
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VG>  wioe  mailing  show 


device 

address 

frequency 

svO; 

0xe00042 

33000  KHz 

svl: 

0xe00043 

43000  KHz 

sv2: 

0xel0044 

53000  KHz 

sv3: 

0xel0045 

63000  KHz 

VG> 

The  mapping  may  be  set  by  use  of  the  "set"  command  in  the  voice  mapping  menu. 
The  example  below  sets  the  "A"  port  on  simvad  device  2  to  be  a  frequency  of  44000 
KHz. 

VG>  voice  mapping  set  2  44000 
VG> 

VG>  voice  mapping  show 


device 

address 

frequency 

svO: 

0xe00042 

33000  KHz 

svl: 

0xe00043 

43000  KHz 

sv2: 

0xel0044 

44000  KHz 

sv3: 

0xel0045 

63000  KHz 

VG> 

12.6.2.8.  Statistics 

The  firmware  will  automatically  restart  all  the  SI[MVAD  cards  in  die  system  and  print  a 
message  to  that  effect  on  the  console  upon  detection  of  a  failure  or  bad  data  fi’om  a 
SIMVAD.  The  count  of  the  number  of  times  an  error  has  been  detected  for  each 
SIMVAD  channel  is  displayed  with  the  other  voice  statistics  as  shown  below: 

VG>  voice  statistics 


frames  input: 


chan 

total 

fr/ls 

fr/lOs 

fr/60s 

0: 

105346 

38 

38 

16 

1: 

105345 

38 

38 

16 

2: 

105347 

38 

38 

16 

3: 

1704 

0 

0 

0 
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dian 

frames  cmtput 

total  fr/ls 

fr/lOs 

fr/60s 

0: 

53732  0 

0 

0 

1: 

56123  0 

0 

0 

2: 

0  0 

0 

0 

3: 

832  0 

0 

0 

chan 

lO  errors: 

total 

0:  0 

1:  0 

2:  0 

3:  0 

This  table  shows  the  total  speech  frames  input  (read)  from  each  channel^  output 
(written)  to  each  chaimel,  and  the  running  average  frame  rates  input  and  output 
averaged  over  1  second,  10  seconds  and  60  sea>nds  for  each  chaimeL  Input  frames 
are  sent  out  over  the  network,  while  output  frames  are  received  from  the  network 
(or  looped  back).  In  the  example  above,  all  four  channels  are  generating  frames  at 
their  maximum  rate  (a  little  less  than  40  per  second)  while  only  chaimels  0  and  1  are 
receiving  frames.  Also,  the  DVGin  the  above  example  has  been  running  for  less 
than  60  seconds  so  that  the  60  second  nmning  averages  are  not  accurate.  Another 
caveat  is  that  the  input  frames  statistic  is  incremented  only  if  die  push-to-talk  and 
speech-valid  tests  (see  above)  are  successful. 

The  total  number  of  resets  that  have  occurred  is  the  sum  of  the  entries  for  all  the 
channels  in  the  lO  errors  section.  The  SIMVADs  may  also  be  restarted  from  the  console 
by  typing  "voice  restart". 

This  ccnnmand  is  useful  for  debugging  in  that  it  provides  information  about  whether 
frames  from  a  particular  voice  channel  are  being  output  after  being  received  from  the 
network.  Also,  a  channel  can  be  put  into  loopback  mode  to  verify  that  speech  frames 
are  being  read  from  it  and  written  out  to  it  (see  section  on  loopback’  atove). 

2.2.6.2.9.  Zerostatistics 

The  voice  statistics  may  be  zeroed  by  typing  the  command 
VG>  voice  zerostatistics 
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22.6S,  Radio  Command  Group 

The  radio  command  group  contains  commands  related  to  radio  identification.  The 
radio  commands  may  be  viewed  by  typing  a  *?'  after  entering  the  ’radio’  command 
(followed  a  space),  as  shown  below: 

VG>  radio? 

Radio  Commands: 

set  -set  radio  site  host  vehicle  and  radio  numbers 

show  -show  radio  parameters  for  one  radio 
all  -show  radio  parameters  for  all  channels 

2^63.1.  Set 

The  ’set’  command  sets  the  radios  site,  host,  vehicle  and  radio  numbers.  Eadt  radio 

must  have  a  unique  id,  which  is  comprised  of  site,  host,  vehicle  and  radio  number. 
These  parameters  are  set  by  assigning  these  numbers  to  a  particular  SIMVAD  channel 
as  shown  in  the  example  below. 

VG>  radio  set  0  2  54 1  0 

VG> 

(This  sets  SIMVAD  channel  0  to  a  site  of  2,  host  of  54,  a  vehicle  of  1  and  radio  0*.) 

A  radio  number  of  0  oonesponds  to  a  standalone  radio  in  foe  SENCGARS 
simulation. 

2J2.63J1,  Show 

The  ’show’  command  shows  foe  current  set  up  for  one  radio  specified.  An  example  of 
foe  ’show’  command  follows. 

VG>  radio  show  0 

Radio  0  Parameters 

Site  ID  is  2  Host  ID  is  54 

Vehicle  ID  is  1  Radio  ID  is  0 

Radio  Frequency  is  44000 

VG> 

23.63.3.  All 

The  ’all’  command  shows  foe  current  set  up  for  all  radios  configured  in  foe  system.  An 
example  of  the  ’all’  commands  output  is  shown  below. 


19 


VG>  radio  all 


VG> 


2^6.4. 


Radio  0  Parameters 
Site  ID  is  2 

Host  ID  is 

54 

VehidelDis  1 

Radio  ID  is 

0 

Radio  Frequency  is 

44000 

Radio  1  Parameters 
Site  ID  is  2 

Host  ID  is 

54 

Vehicle  ID  is  2 

Radio  ID  is 

0 

Radio  Frequency  is 

43000 

Radio  2  Parameters 
Site  ID  is  2 

Host  ID  is 

54 

Vehicle  ID  is  3 

Radio  ID  is 

0 

Radio  Frequency  is 

45000 

Radio  3  Parameters 
Site  ID  is  2 

Host  ID  is 

54 

Vehicle  ID  is  4 

Radio  ID  is 

0 

Radio  Frequency  is 

46000 

Network  Command  Group 

The  network  conunand  group  contains  commands  related  to  network  input  and 
output  The  network  commands  may  be  viewed  by  typing  a  '?'  after  entering  the 
'network'  command  (followed  by  a  space),  as  shown  below: 
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VG>  network  ? 
Network  Commands: 


voiceaddress 

-show  ethemet  address  for  voice  traffic 

setvoiceaddress 

-set  ethemet  address  to  for  voice  traffic 

myaddress 

-display  ethen^t  address  of  this  station 

getstats 

-show  low-level  network  statistics 

zerostats 

-zero  network  statistics 

packetstats 

-show  packet  statistics 

zerop>acketstats 

-zero  packet  statistics 

bufferstats 

-show  buffer  statistics 

zerobufferstats 

-zero  buffer  statistics 

setaggregation 

-set  max  pdus  per  packet 

aggregation 

-show  max  pdus  per  packet 

settype 

-set  Ethemet  packet  type 

type 

-show  Ethemet  packet  type 

exerciseid 

-show  exercise  id 

setexerdseid 

-set  exerdse  id 

2^6.4.!.  Voiceaddress 

The  'voiceaddress'  command  displays  the  current  Ethernet  address  that  the 
transmitter  and  signal  packets  are  bdng  sent  to  and  received  from^  as  shown  below. 

VG>  network  voiceaddress 

transmitter  address:  03  00  00  00  00  89 

signal  address:  03  00  00  00  00  86 

The  voice  address  is  specified  as  six  hexadecimal  bytes  separated  by  spaces.  The 
bytes  are  transmitted  in  the  order  specified,  with  bits  within  a  byte  transmit^  starting 
hrom  the  least  significant.  This  is  configured  in  software,  and  ^e  user  cannot  alter  its 
value. 

22.6.4.2.  Setvoiceaddress 

The  'setvoiceaddress'  command  is  a  carry  over  from  previous  versions  of  the  DVG.  The 
'setvoiceaddress'  command  will  print  a  message  to  the  screen  as  shown  below: 

VG>  network  setvoiceaddress 

The  Transmitter  PDU  and  Signal  PDU  destination 
addresses  are  configured  automatically. 

22.6.4.3.  Myaddress 

The  'myaddress'  command  displays  the  Ethernet  address  of  the  DVG  as  shown  below. 
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VG>  netwcvk  myaddress 

ethernet  address:  08  00  3e  20  46  74 
The  address  is  obtained  from  a  ROM  on  the  DVG  CPU  card. 

2JL6.4.4.  Getstats 

The  command  'getstats*  displays  statistics  horn  the  Ethernet  driver  software.  A  typical 
display  produced  by  dus  command  is  shown  below. 


VG>  network  getstats 
successful  transmissions 

1296740 

multiple  retries  reported 

1 

single  retries  reported 

4 

retry  failures  reported 

0 

deferrals  report^ 

125 

bufrer  errors 

0 

siloimderruns 

0 

late  collisions 

0 

carrier  losses 

0 

babbling  transmitter  errors 

0 

collisions  errors 

1280633 

memory  errors 

0 

packets  received 

970076 

missed  packets  reported 

0 

CRC  erro:s  reported 

0 

framing  errors 

0 

silo  overruns 

0 

stp  bit  missing 

0 

enp  bit  missing 

0 

lance  errors 

0 

non-SIMNET  packets 

0 

packets  filtered 

0 

packets  missed  >  table  locked 

0 

packets  missed  -  index  out  of  range 

0 

This  command  is  especially  useful  for  diagnosing  physical  Ethernet  problems  such 
as  loose  cables.  The 'successful  transmissions' statistic  should  inaement  as  SINCGARS 
packets  are  successfully  sent  over  the  network  by  the  DVG.  Likewise,  d\e  'packets 
received'  statistic  should  increment  as  packets  of  any  type  are  received  from  the 
network  by  the  DVG.  Physical  Ethernet  problems  are  in^cated  if  any  of  the  following 
statistics  are  incremented: 
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retry  failures  reported 
late  collisions 
cairior  losses 

babbling  transmitter  errors 
CRC  errors  reported 
framing  errors 

2JL6.4.5.  Zeiostats 

The  'zerostats'  command  zeros  the  low-level  Ethernet  statistics  displayed  by  the 
'getstats'  command.  It  is  invoked  as  shown  below. 

VG>  network  zerostats 
2JL6.4.6.  Packetstats 

The  'packetstats*  command  displays  network  packet  statistics  of  the  DVG  as  shown 
below. 


VG>  network  packetstats 
packet  statistics: 

total 

ppsls 

pps  los 

pps  60s 

signal  received 

6580 

78 

82 

80 

transnutter  received 

6580 

78 

82 

80 

signal  sent 

6580 

78 

82 

80 

transmitter  sent 

6580 

78 

82 

80 

total  received 

6580 

78 

82 

80 

total  sent 

6580 

78 

82 

80 

bad  pkts 

0 

0 

0 

0 

Totals  for  all  packets  received  and  sent  and  for  transmitter  and  signal  packets  received 
and  sent  are  displayed,  along  with  running  averages  for  each  category  averaged 
over  1  second,  10  seconds  and  60  seconds.  Each  voice  channel  will  average  a  little 
less  than  40  pac^ts  per  second  while  active  so  that  a  four  channel  DVG  can  generate  a 
maximum  of  about  160  packets  per  second.  This  command  is  useful  for  debugging 
since  it  provides  an  indication  of  whether  a  DVG  is  generating  or  receiving  voice  and 
other  network  packets. 
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12.6,4t.7.  Zeropacketstats 

The  'zeropacketstats'  command  zeros  all  the  counters  used  for  the  'packetstats* 
command.  It  is  invoked  as  shown  below. 

VG>  network  zeropacketstats 
12.6.4.8.  Bufferstats 

The  'bufferstats'  command  displays  the  status  of  the  DVG's  internal  buffering  system 
as  shown  below. 

VG>  net  bufferstats 


buffer  statistics: 
total  buffers  140 

bilkers  in  use  8 

max  buffers  used  9 

times  out  of  buffers  0 

total  headers  192 

headers  in  use  8 

max  headers  used  9 

times  out  of  headers  0 


This  command  is  most  useful  during  develo ,  ment.  If,  however,  the  following  fields 
are  ever  non-zero 

times  out  of  buffers 

times  out  of  headers 

or  if  the 'max  buffers  used'  field  approaches  the  'total  buffers'  field,  or  if  the  'max 
headers  used'  field  approaches  the 'total  headers'  field,  the  DVG  developers  should 
be  notified. 

22.6.4.9.  Zerobuffeistats 

The  'zerobufferstats'  command  zeros  the  counters  used  by  the  'bufferstats'  command.  It 
is  invoked  as  shown  below. 

VG>  network  zerobufferstats 
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2^6.4.10.  Setaggiegation 

The  'setaggregation*  command  sets  the  maximum  number  of  speech  frames 
aggregated  into  a  single  Ethernet  packet  as  shown  below. 

VG>  network  setaggregation  4 

The  above  example  sets  the  maximum  to  4  frames  per  packet  The  current  value  of 
the  maximum  frames  per  packet  may  be  displayed  using  the  'aggregation'  command. 
The  setaggregation  command  will  allow  setting  of  a  number  but  has  no  effect  on 
aggregation  for  version  2.00  Qt  is  always  1). 

2.2.6.4.11.  Aggregation 

The  'aggregation'  command  shows  the  current  maximum  number  of  speech  frames 
aggregated  into  a  single  Ethernet  packet  as  shown  below. 

VG>  network  aggregation 

max  pdus  per  packet » 1. 

2.2.6.4.12.  Settype 

The  'settype'  command  sets  the  Ethernet  packet  type.  Currently  the  DVG  uses  the 
PR0T0C0L_SIM  type  which  is  21000.  The  settype  command  is  demonstrated  below. 

VG>  network  settype  21000 

VG> 

2JL6.4.13.  Type 

The  'type'  command  displays  the  current  setting  of  the  Ethernet  packet  type.  This  will 
be  21000  by  default  for  ^e  DVG.  This  command  is  demonstrated  below. 

VG>  network  type 

VG>  Ethernet  type  =  21000  =  0x5208 
2.2.6.4.14.  Exerciseid 

The  'exerdseid'  command  displays  the  current  setting  of  the  exercise  id  for  the 
simulation.  The  DVG  currently  supports  one  exercise  id.  This  command  is 
demonstrated  below. 
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22.6.4.15.  Setexexdseid 

The  'setexerdseid*  sets  the  exerdse  id  for  the  current  simulation.  This  is  demonstrated 
in  the  example  below. 

VG>  network  setexerdseid  2 
VG> 


22.6.5.  System  Command  Group 

The  system  command  group  consists  of  commands  diat  are  of  a  general  system  nature. 
The  system  command^  may  be  viewed  by  typing  a  '?*  after  entering  the  'system' 
command  (followed  by  a  space),  as  shown  below: 

VG>  system  ? 

System  Commands: 

version  -version  and  creation  date 

timing  -show  system  timing 

debug  -debug  commands 

22.6.5.1.  Version 

The  'version'  command  displays  the  version  number  and  creation  date  of  the  DVG 
firmware  as  shown  below. 

VG>  system  version 

version  2.00  of  Thu  Nov  16 15*36:47  EST 1993 


22.6.5.2.  Timing 

The  'timing*  command  displays  system  timings  as  shown  below. 


VG>  system  timing 

min 

ave 

max  (ms) 

total  interrupt  time 

2.00 

3.66 

6.00 

network_serviceO 

0.00 

1.23 

3.00 

simvads_serviceO 

1.00 

2.38 

4.00 

The  minimum,  average  and  maximum  times  (in  milliseconds)  are  displayed  for  the 
master  interrupt,  the  network  service  time  and  the  SIMVAD  service  time. 

22.6.6.  Configuration  Command  Group 

Configuration  Control  Commands  identical  to  those  typed  to  the  console 
interface  may  be  stored  in  the  battery-backed  ram.  These  commands  can  be  entered 
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<moe  and  will  then  be  automatically  executed  after  rebooting  or  power  cycling.  The 
config  entry  in  the  top  levd  menu,  supports  management  of  the  contents  of  the  lottery- 
back^  ram.  The  config  menu  is  shown  below. 

VG>  config  ? 

Configuration  Commands: 

delete  -delete  line 

exec  -execute  configuration 

init  -initialize  (erase)  battery-backed  RAM 

insert  -insert  line 

list  -list  lines 

location  -set  memory  address  of  config  buffer 

2^6.6.!.  List 

The  ’list'  command  lists  the  contents  of  the  battery  backed  ram. 

2^6.6.2.  Insert 

A  line  may  be  inserted  into  battery  backed  ram  using  the  'insert'  command  followed  by 
a  line  number  and  the  commands  desired  enclosed  in  double  quote  marks  The 
following  shows  an  example  of  the  contents  of  the  battery  backed  ram  before  and  after 
inserting  a  line  to  change  die  Ethernet  type  code  used  for  DVG  packets.  The  numbers  to 
the  left  of  each  line  followed  by  a are  line  numbers. 

VG>  config  list 

0:  network  setaggregation  1 
1:  voice  mapping  set  0  44000 
2:  voice  mapping  set  1 43000 
3:  voice  mapping  set  2  44000 
4:  voice  mapping  set  3  45000 
VG>  config  insert  1  "network  settype  21000" 

VG>  config  list 

0:  network  setaggregation  1 
1:  network  settype  21000 
2:  voice  mapping  set  0  44000 
3:  voice  mapping  set  1 43000 
4:  voice  mapping  set  2  44000 
5:  voice  mapping  set  3  45000 
VG> 


2^6.6.3.  Delete 

A  line  may  be  deleted  by  typing  "config  delete  N",  where  N  is  the  line  number  to 
delete. 


27 


2^&6.4.  Ixiit 

The  battery-backed  ram  may  be  erased  by  typing  "config  init". 


Z2.6.6.5.  Exec 

The  current  configuration  may  be  executed  by  typing  "config  exec". 

12.6.6.6.  Location 

The  memory  location  of  the  battery  backed  ram  may  be  specified  using  the  'location' 
command  followed  by  a  memory  location. 

12.6.6.7.  Exit  Command 

The  'exif  ccxnmand  causes  the  DVG  firmware  to  return  to  the  ROM  monitor,  147Bug,  as 
shown  below. 

VG>  exit 

147-Bug> 

All  voice  processing  ceases  upon  execution  of  this  command. 

22.6.6.8.  Quit  Command 

The  'quit'  command  is  equivalent  to  the  'exit*  command. 

22.6.7.  Help  Command 

The  'help*  command  presentiy  only  directs  the  user  to  type  a  '?'  for  help,  as  shown 
below. 

VG>  help 

try"?"  for  help 

3.  Software  Configuration 

This  secdon  discusses  toe  software  configuration  of  toe  DVG. 

3.1.  DVG  Firmware  ROMS 

The  DVG  firmware  is  conteiined  in  two  1  Mbit  EPROMs.  The  two  chips  bear  labels 
similar  to  those  shown  below: 


DVG 

VERX.YZ 

HI 


DVG 

VERX.YZ 

LO 
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where  X.YZ  is  the  current  version  number  and  HI  and  LO  refer  to  the  upper  and 
lower  bytes  the  two  byte  width.  The 'HT  diip  is  inserted  into  empty  socket  U16  and 
the  'LO*  chip  is  inserted  into  empty  socket  U18  on  the  CPU  board 

3^  MVME147  Firmware  Configuration 

The  MVME147  CPU  debugger,  147Bug,  must  be  configured  for  use  in  the  DVG.  To 
obtain  a  full  description  of  the  commands  available  fiom  the  debugger,  refer  to  the 
MVME147Bug  User's  Manual.  The  following  procedure  can  be  used  to  configure  an 
MVME147  as  it  comes  from  the  manufiicturer. 

When  fixe  debugger  is  first  brought  up  following  a  power-up  or  reset,  the  following  is 
displayed  on  the  console  port: 

Copyright  Motorola  Inc.  1988,  All  Rights  Reserved 
VME147  Monitor/Debugger  Release  2.0  -  3/16/89 
FPC  passed  test 
MMU  passed  test 
COLD  Start 

followed  by  a  rapid  display  of  test  result  messages  at  the  bottom  of  the  screen.  Press 
the  black  'ABORT  button  on  tiie  front  panel  of  &e  MVME147  to  obtain  the  following 
menu: 


1)  Continue  System  Start-up 

2)  Select  Alternate  Boot  Device 

3)  Go  to  System  Debugger 

4)  Initiate  Service  Call 

5)  Display  System  Test  Errors 

6)  Dump  Memory  to  Tape 
Enter  Menu  #: 

Type  a '3' followed  by  a  Hetum' to  obtain  the  diagnostic  prompt  ('147-Diag>').  Then 
enter  the  'env'  command  to  set  the  operating  environment  to  'Bug'  as  shown  below.  On 
the  first  question  respond  with  a'b'.  On  all  the  following  questions,  respond  with  a 
'Return'  to  select  the  default. 

147-Diag>env 

Bug  or  System  environment  [B,S]  =  S?  b 

SYSTEM  V/68  or  VERSAdos  operating  system  [S,V]  =  S? 

Set  VME  Chip: 

Board  ID  [0-FF]  =  $00? 

GCSR  base  address  [O-OF]  =  $0F? 

Utility  Interrupt  Mask  [0-FE]  =  $00? 

Utility  Interrupt  Vector  [$20-$3E0]  =  $0180? 

Copyright  Motorola  Inc.  1988,  All  Rights  Reserved 
VME147  Monitor /Debugger  Release  2.0  -  3/16/89 
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FPC  passed  test 
MMU  passed  test 
COLD  Start 
147-Bug> 

The  147Bug  prompt  should  now  be  displayed  on  the  console  as  shown  in  the  above 
example. 

Next  configure  the  firmware  to  boot  from  the  EPROMs  by  typing  the  'rb'  conunand,  as 
shown  below. 


147-Bug>rb 

Boot  at  power-up  only  [YJN]  ?  Y  n 

Enable  search  of  VMEbus  [Y^]  ?  N  n 
Boot  direct  address  s  $FF800000  FFAOOOOO 
147-Bug> 

Respond  with  the  answers  'n',  to  boot  at  both  power-up  and  any  reset,  'n*  to  disable 
sea^  of  the  VMEbus,  and  'FFAOOOOO'  to  set  the  boot  address  to  that  of  the  DVG 
EPROMs. 


At  this  point,  power  cycling  the  system  or  pressing  the  reset  button  should  boot  the 
DVG  firmware  (if  the  DVG  EPROMs  have  been  installed).  Refer  to  the  section  on  'Boot¬ 
up  an  Initialization'  for  a  description  of  the  boot  process. 


33.  DVG  Firmware  Configuration 

The  DVG  firmware  operating  parameters  may  be  configured  from  the  console  port  via 
the  DVG  Terminal  Interface  described  in  the  section  titled  Terminal  Interface'.  The 
parameters  that  nuiy  presently  be  configiued  are: 

Ethernet  address  for  voice  traffic 
exercise  ID 

radio  id's  for  each  SIMVAD  channel 
ethemet  type 

frequency  mapping  for  each  SIMVAD  diannel 

voice  channel  loopback 

push-to-talk  input  checking 

speech-valid  checking 

speech-valid  threshold 

speech  coding  rate 
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4.  Haidwaze  Configuration 

4.1.  MVME147CPU 

The  jump«r  configuration  for  foe  MVME147  CPU  is  shown  in  Figure  1.  This  is  foe 
standard  configuration  supplied  foe  manufacturer. 

The  DVG  EPRC^ds  must  be  inserted  into  MVMEl^  sockets  U16  and  U18.  The  DVG  Pil 
EPROM  goes  into  position  U16  and  foe  DVG  LO  goes  into  position  U18. 

4.2.  MVME712M  Transition  Module 
MVME712M  Configuration: 

The  MVME712M  adapter  is  configiired  as  shown  in  Figure  2.  Ports  2  through  4  are 
configured  for  connection  to  a  modem  while  port  1  is  configured  for  connection  to  a 
terminal  via  a  straight-through  cable  with  a  male  connector  onfoeMVME712M 
end. 

Cables  are  routed  from  MVME712M  connectors  J2  and  J3  to  foe  P2  adapter  module 
plugged  into  foe  P2  connector  of  foe  back  plane. 

43.  SIMVAD  Speech  Coding  Board 

The  jumper  configuration  of  foe  SIMVAD  speech  coding  board  is  shown  in  Figure  3. 

The  SIMVAD  board  has  two  jumpers,  El  and  E2  that  are  for  manufacturing  and 
development  use  only.  These  should  be  installed  on  all  boards. 

The  SIMVAD  has  a  single  dip  switch  pack,  SW2,  which  sets  foe  base  address  of  foe 
board  in  foe  VMEbus  foort  I/O  space.  The  standard  configuration  DVG  contains  two 
SIMVAD  boards  for  a  total  of  four  voice  channels  numbered  0  through  3.  The  table 
below  shows  how  to  set  SW2  for  each  of  foe  SIMVAD  cards  up  to  a  total  of  eight 
(although  only  two  SIMVAD  cards  are  used  in  foe  DVG). 
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Card 

1 

2 

3* 

4* 

5* 

6* 

7* 

8* 


Channels  Address  SW2  (8  through  1) 

0,1  OxEOOOOFFOFFOFF  ON  ON  ON  ON  ON 

2,3  OxElOO  OFF  OFF  OFF  ON  ON  ON  ON  OFF 

4,5  0xE200  OFF  OFF  OFF  ON  ON  ON  OFF  ON 

67  0xE300  OFF  OFF  OFF  ON  ON  ON  OFF  OFF 

8,9  0xE400  OFF  OFF  OFF  ON  ON  OFF  ON  ON 

10,11  OxESOO  OFF  OFF  OFF  ON  ON  OFF  ON  OFF 

12,13  0xE600  OFF  OFF  OFF  ON  ON  OFF  OFF  ON 

14,15  OxE700  OFF  OFF  OFF  ON  ON  OFF  OFF  OFF 


*Not  currently  used. 


4.4.  VMEbus  Bade  plane 

The  table  below  shows  which  slots  the  circuit  cards  should  be  plugged  into. 

SLOT*  BOARD  COMMENTS 

1  MVME147  CPU  system  controller 

2  SIMVAD  channels  O&l,  address  s  OxEOOO 

3  SIMVAD  channels  2&3,  address  =  OxElOO 

4  Empty 

5  Empty 

6  Empty 

7  Empty 

8  Empty 

9  Empty 

10  Empty 

11  Empty 

12  Empty 

*Slot  1  is  at  ^e  left  when  facing  the  front  of  the  Chassis. 

Even  numbered  channels  are  the  top  DB9  connector  on  a  SIMVAD  board  while  odd 
numbered  channels  are  the  bottom  DB9  connector. 

Each  slot  has  5  jumpers  associated  with  it  (to  the  right  of  the  slot,  refer  to  Rgure  4.). 
The  group  of  4  jximpers  labeled  BG  pass  the  bus  grant  signals  through  slots  that  do  not 
have  a  card  installed.  The  single  jumper  labeled  lACK  propagates  the  interrupt 
acknowledge  signal  through  slots  that  do  not  have  a  card  instiled.  FortheDVG,  no 
slot  in  die  ^ck  plane  should  have  jumpers  installed  in  it. 


4.5.  Rear  I/O  Connectors 

The  MVME147M  transition  module  should  be  installed  in  place  of  the  two  right-most 
blanks  as  shown  in  Figure  5.  The  remaining  12  blanks  should  remain  installed. 
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4^  F2  Adapter 

The  P2  adapter  board  is  plugged  into  the  rear  of  connector  P2  of  slot  1  of  the  back 
[dane.  Ribbon  caldes  supplied  with  the  P2  adapter  and  MVME712M  transition  module 
are  routed  internal  to  the  chassis  as  indicated  below.  Figtire  6  shows  how  the  P2 
adapter  is  inserted  into  the  back  of  the  VMEBus  (viewed  from  the  rear  of  the  chassis). 


MVME712M 

P2  Adapter 

Size 

J2  to 

J2 

64  conductor 

J3  to 

J3 

50  conductor 
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4.7.  Paits  List 


Quantity 

Part 

Manukcturgr 

Description 

1 

MVME147-1 

Motorola 

CPU,  VMEBus  25MHz 

68030  with  4MB  RAM 

1 

MVME712M 

Motorola 

transition  module  &  P2 

adapter  with  cables 

2 

SIMVAD 

BBN 

speech  coding  board, 

two  channels 

1 

Chassis 

MUPAC 

5098GCE12VK-104 

12  slot  VME  chassis 

with  power  cord 

2 

EPROM 

Mitsubishi 

:.15M27C101K-15 

1  Mbit,  150  nanosec 

1 

Cable??? 

Ethernet  transceiver 

cable 

34 


Connector  P2 


Connector  P1 


Figure  1.  MVME147  configuration.  Component  side  up. 


35 


Faceplate 


Figure  2.  MVME712M  Transition  Module.  Component  side  up. 
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Connector  P1 


Figure  3.  SIMVAD  configuration.  Component  side  up. 
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Figure  4.  VMEbus  Jumpers. 
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Figure  5.  Rear  view  showing  I/O  connections. 


